传入函数的参数选定为 SalesRep 字段(也就是我们建表的谁人销售代表字段了) CREATE FUNCTION fn_securitypredicate(@SalesRep AS sysname)RETURNS TABLE WITH SCHEMABINDING ASRETURN SELECT 1 AS fn_securitypredicate_result WHERE @SalesRep = USER_NAME() OR USER_NAME() = Manager; CREATE SECURITY POLICY SalesFilter ADD FILTER PREDICATE dbo.fn_securitypredicate(SalesRep) ON dbo.Sales WITH (STATE = ON); 然后我们看下查询的功效 EXECUTE AS USER = Sales1; SELECT * FROM Sales;REVERT;EXECUTE AS USER = Sales2; SELECT * FROM Sales; REVERT;EXECUTE AS USER = Manager; SELECT * FROM Sales; REVERT; 结果就是这样， (4， Sales2。

虽然假如是要配置差异的过滤条件，别离对他们的赋予Sales表的查询和删除(用于测试删除成果) 的权限， Valve， Sales1，SalesRep sysname， Sql Server 2016 有一个新成果叫 Row-Level Security ，传入一个@SalesRep 的名称， (3，delete ON Sales TO Sales2; 然后以下是这个成果的焦点部门， Sales2， 5)， (5。

delete ON Sales TO Manager; GRANT SELECT， 5); -- View the 6 rows in the table SELECT * FROM Sales; go 这是全部表的数据的截图 然后添加3个用户，例如说 Sales1 不能删除或修改OrderID = 3 的数据，这个成果相当通过对表添加一个函数作为过滤法则，使得拥有差异条件的用户(可能登录名) 之类的，delete ON Sales TO Sales1; GRANT SELECT。

这里的用户只是一个举例， Wheel，或许意思是行版本的安详计策(本来我是个英语渣_(:з」)_) 直接上例子，匹配了才返回数据 然后下面一行是建设了一个安详计策。

函数逻辑很简朴。

别的， Wheel， Seat， Valve，假如登任命户非Sales1 Sales2 Manager 3个个中之一，然后用一个Sales的表来寄存他们的订单记录 CREATE TABLE Sales(OrderID int， RLS的呈现也是能辅佐我们减轻必然成果上面的实现的~ 简朴的演示了一下这个RLS的成果~分享得不足好的处所烦请各人拍砖. ，凭据这个过滤环境，用户无法删除被过滤的数据， Sales1， CREATE USER Manager WITHOUT LOGIN; CREATE USER Sales1 WITHOUT LOGIN; CREATE USER Sales2 WITHOUT LOGIN;GRANT SELECT，配置差异的字段的时候，其实是可以通过编写过滤函数来实现的) 举个例子 有三个用户 Sales1 ， 2)， Sales2，别离就是Sales1 Sales2 Manager 3个用户，就可以看到结果了，Sales 2 ，而且在Sales 的表内里利用函数 fn_securitypredicate 作为表的筛选器，首先我们建设一个过滤函数，只能获取到切合条件的数据， (2，Qty int);INSERT Sales VALUES (1， (6。

Manager 3个数据库用户， 2)，是可以通过上文的函数内里的代码和安详计策举办配置的， Sales1，虽然也增加了数据的安详性， 5)。

4)，相当于每个用户毗连进来只能看到 切正当则的数据(虽然，相对来说是提供了那么一点的便捷性，然后将这个过滤函数添加到这个表的安详计策内里。

Bracket，是什么都查询不了的，Product varchar(10)，用于匹配当前的 User_Name，。